This invention relates generally to simulating and/or testing electronic devices, and, more particularly, to facilitating comparisons between the behavior of a device predicted by a simulation and the behavior of a corresponding physical device exercised on a tester.
When a designer develops a new electronic device, the designer generally concurrently develops a software model for the new device. The software model simulates the behavior of a physical device by producing output data in response to input data analogously to the way in which the physical device produces output signals in response to input signals.
A software model, once developed, can be made available to aid in developing a test program. A test program is a software program that runs on a tester for testing actual, physical devices. A conventional process for developing a test program is shown generally in FIG. 1. An engineer acquires the device model (step 110) and generates xe2x80x9ctest patterns,xe2x80x9d i.e., sequences of data that correspond to input signals that are to be applied to inputs of an actual device under test (DUT) during operation of the test program on a tester (step 112). The engineer applies the test patterns to the device model. In response, the device model generates response data (step 114). Using the response data, as well as knowledge about the device and about the target tester, the engineer generates xe2x80x9cexpect data,xe2x80x9d i.e., expected values of output signals from DUT in response to the test patterns during the execution of the test program.
To implement a test program for use with a particular target tester, a test engineer translates the simulated test patterns and expect data into software instructions that are compatible with the target tester (step 116). The test engineer stores the software instructions in the test program (step 118) and debugs the test program by running it on the tester to test actual, physical devices (step 120). The test engineer may alternatively debug the test program in a software environment that simulates both the tester and the device under test. Under control of the test program, the tester (or simulated tester) applies stimuli to inputs of a DUT (or simulated DUT), and captures responses from outputs of the DUT (or simulated DUT). The tester compares the captured responses with expect data stored in the test program. If the responses match the expect data, the test program passes. Otherwise, the test program fails.
Test programs commonly fail when first run, even when testing known-good devices. The reasons for this are varied, and include inaccurate data used to generate device models, failure to account for normal semiconductor process variations, and other sources. To address these problems, test engineers customarily modify the test programs (step 122), test the changes, and repeat as needed to yield more reliable test programs. Eventually, the test program passes and is deployed to a testing facility for performing volume production testing.
Test engineers generally develop and debug test programs with only limited access to testers and with only limited numbers of actual devices. Consequently, problems with test programs often do not arise until after the test programs have been deployed. The personnel at the testing facilities generally lack expertise in test program development and in the test programs for specific devices. When a test program fails while testing a device that is believed to be good, the testing facility may halt production until the source of the problem is identified and the problem is solved. The testing facility generally falls back on the test engineer responsible for the test program to receive assistance. Messages from the testing facility usually take the form of emails, faxes, or telephone calls, which describe the nature of the failure. The test engineer receives the messages and prepares responses for the testing facility. In preparing responses, the test engineer may consult with device designers and examine simulations of the device. The test engineer""s responses generally take the form of emails or faxes, which includes suggestions for modifying the test program. They may also include revised software, transmitted electronically or via a physical storage medium.
This method of troubleshooting test programs involves several drawbacks. For example, the test development facility may be physically distant from the testing facility, making direct communication difficult. Different time zones, languages, and areas of expertise can significantly impair the ability to develop speedy solutions to test program failures. It often happens that a test engineer flies to Asia on a lengthy support mission, only to discover that the problem is one that could have been solved easily without the trip if better information had been available. Perhaps more significantly, test program failures can bring a production line to a complete halt until the failures are resolved. The opportunity cost of halting a production line can quickly rise to an excessive level.
With the foregoing background in mind, it is an object of the invention to facilitate understanding of the behavior of an electronic device exercised by an automatic test system.
To achieve the foregoing object, as well as other objectives and advantages, a system for examining the behavior a device exercised by an automatic test system includes a first collection of data for storing simulation values and a second collection of data for storing actual waveform values. The simulation values include test patterns representing inputs of a device model and response data representing outputs of the device model. They may also include expect data representing expected values of the response data. The actual waveform values include sampled inputs and/or outputs of an actual device under test (DUT) acquired using an electronic test system. When a tester exercises the DUT with test patterns that correspond to the test patterns stored in the first collection of data, the DUT generates output that can be compared directly with the response and/or expect data stored in the first collection of data. Software is included for aligning the data stored in the first and second collections of data, so that simulated and actual values can be readily compared. Analysis tools are included for examining similarities and differences between simulated and actual behavior. These may include a graphical display for visually representing simulated and actual values. The graphical display enables a user of the system to identify instances in which the actual behavior of a DUT deviates from the simulated behavior.